Its not a secret that I’ve been working on sandboxed desktop applications recently. In fact, I recently gave a talk at devconf.cz about it. However, up until now I’ve mainly been focusing on the bundling and deployment aspects of the problem. I’ve been running applications in their own environment, but having pretty open access to the system.
Now that the basics are working it’s time to start looking at how to create a real sandbox. This is going to require a lot of changes to the Linux stack. For instance, we have to use Wayland instead of X11, because X11 is impossible to secure. We also need to use kdbus to allow desktop integration that is properly filtered at the kernel level.
Recently Wayland has made some pretty big strides though, and we now have working Wayland sessions in Fedora 21. This means we can start testing real sandboxing for simple applications. To get something running I chose to focus on a game, because they require very little interaction with the system. Here is a video I made of Neverball, running in a minimal sandbox:
In this example we’re running a regular build of neverball in an environment which:
- Is independent of the host distribution
- Has no access to any system or user files other than the ones from the runtime and application itself
- Has no access to any hardware devices, other than DRI (for GL rendering)
- Has no network access
- Can’t see any other processes in the system
- Can only get input via Wayland
- Can only show graphics via Wayland
- Can only output audio via PulseAudio
- … plus more sandboxing details
Yet the application is still simple to install and integrates nicely with the desktop. If you want to test it yourself, just follow the instructions on the project page and install org.neverball.Neverball.
Of course, there are still a lot to do here. For instance, PulseAudio doesn’t protect clients from each other, and for more complex applications we need to add new APIs to safely grant access to things like user files and devices. The sandbox details page has a more detailed list of what has to be done.
The road is long, but at least we have now started our journey!
I must say this is a nice development for anyone that is security conscious. As a developer, I know how easy it would be to make something malicious, and often worry about what might be in things I install.
I have developed Firefox extensions, and one great thing when you create them, is they can do anything Firefox can do. The down side, and what a lot of uses don’t realise (they are just add-ons) is that means they have all the access that Firefox does. I can’t want till this is good enough to run Firefox in a sandbox.
Yup, a minimal browser style stuff running in sandbox environment could make xdg-app a game changer. Shipping app via node-webkit package makes the app size run into 100 mb. A bare minimum skeleton is needed to keep app size and footprint lightweight.
I concur entirely. Exactly this is what has been missing from operating systems since 2 decades. All the malware is not just due to stupid users, but due to the security design of Windows, Mac OS X and Linux (they are all the same here): Once an app is installed, it acts as proxy for the end user and can do everything the end user can. Open-source EROS, Microsoft’s “Simplicity OS” and later Android and iOS showed that there are other ways.
It was only a matter of time until somebody ports this concept to Linux. It’s very urgently needed, and critical for all of our security. Including power users – as you said yourself, I cannot verify every single app I install.
It will be important to get the permissions system right. One problem with Android is that it’s an all-or-nothing, both from the app side – as app, I have to grab all permissions at install time, everything that I might possibly need, even if I never need them for this user – and from the user side – if I want to use Firefox, I have to grant it all the access to webcam, microphone, WiFi etc., even if I don’t want to use these particular features. What’s needed is an optional permission system, and a fine-grained one, down to specific hosts/networks/domains, and specific directories, and on an as-needed basis, in the moment when the user needs the access, not at install time.
Can applications running in your sandbox fully comply with LGPL licenses? For other sandbox environments, the sandbox prevents full compliance with GPL/LGPL, particularly for non-GPL applications making use of LGPL components. This is why several commercial component vendors with dual license LGPL/Paid-commercial components say that the commercial license is required for sandboxed environments like app stores/etc… In some cases, they say this even for fully open source apps (case in point: Xamarin’s products) because of application signing requirements. It would be a shame if Linux, the last bastion of GPL/LGPL application development, were suddenly unable to distribute applications that can comply with GPL/LGPL.
The preferred solution for LGPL compliance would be where the application specifies a set of resources/dynamic libraries/etc… that can be modified by the user without re-signing or re-linking the application.
Jeremy:
I don’t see how the sandboxedness would affect licence compliance at all.
The reason GPL etc are not compatible with app stores are in general due to the legal requirements for shipping from the stores, not technical reasons.
In the end the sandboxed app is just a bunch of files on disk. You can easily replace any LGPL shared libraries in there.
It’s a shame you had to shit on a lovely technical achievement with the usual license whinging.
Great work! I’ve been waiting for something like this for a long time. However, I’m wondering if there are any plans for allowing sandboxes that do not have direct access to graphics hardware? If the application requires OpenGL support it will have to fall back to software rendering.
The reason I’m asking is that it is likely that something as complex as a graphics card and its associated firmware will contain at least some security related bugs. I would be quite happy to accept a performance hit for certain applications which are likely targets for malware (e.g. mail readers, web browsers, chat clients, etc).
Andreas:
Sure, it should be possible to use the regular shared-memory passing wayland transport and disallow GL access to an app.
Of course, the app itself would need to be able to handle it, and can’t rely on OpenGL support. Something based on gtk3 should just work though.
I think the system should provide the software GL fallback, not the app. Otherwise, too many apps and games just demand hardware GL and won’t work without, and I’m not better off than before.
I agree with the original post that hardware GL is a big concern for security, esp. in new “unified memory” architectures where the graphics card has access to app RAM, and is programmable and with rich instruction set surface.
If it’s sandboxed, how are you able to record a movie of it?
John: Because i record outside the sanbox.
Compatibility is the other major problem no one is heeding: the Linux Foundation has to specify system libraries right down to the versioning before Linux can be a viable OS for the masses (I’m tired of seeing a binary run on Fedora but fail due to the abscence of/incompatibilities with shared libs on my home Debian system). Microsoft, Apple and the BSD people have had that solved from the start. Otherwise sandboxing apps is only solving half the problem.
Yoko:
With xdg-app, the runtime an app uses is disconnected from the libraries the distro ships, so compatibility is not a problem.
Also, you can install and use multiple runtimes at the same time.
What I’d love to see is sandboxing for regular applications (system packages) that are installed in /usr. And limited access to /home, possibly by not granting direct access but passing fds via dbus.
I don’t want bundled apps and runtimes.
That’s quite awesome!
I remember that at some point, you started glick2. Is it considered like the next step to the bundle concept and glick2 is a dead project?
Also what’s the overhead of the sandboxing? I’m thinking of big applications which can already be quite slow when they have direct access to the system, normally installed. So I’m wondering if the additional layer could make them less usable…
In any case, that’s really good news. Many Free Software projects provide recent releases for proprietary systems only (Windows, OSX…); but for Linux, they just say “install from your app manager”, which is very acceptable when you have basic usage of the app. But when you are looking for new features, that’s very frustrating to users to not be able to install recent applications (because they often take weeks, if not months or years for some distributions, to be packaged). Some software provides .rpm or .deb but this is still a limited set of distributions (and sometimes even may break depending on the distribution version). Some (like Blender, or Mozilla) would provide an archive to uncompress, with every dependency, but that’s *really* not integrated to the desktop and quite ugly way of “installing”.
I’m really looking forward to bundles independant of host distribution that projects could provide for download!
This is the part I am mostly interested in. And if I understood this project correctly, that’s what you are working on (maybe not the only goal, but end user is also a target, right?). Moreover if it can be made in a safe way, that’s even better of course.
For many of the apps I’m thinking of though, there will definitely need more access (the safe access to files and devices you told about in particular).
This is the true key to the bright future of Free Software (not “free” software like it was before). Keep going!
Yeah. Sandboxing when you can use the kernel’s namespace facilities to do it for you. I even have my own single file implementation at https://gitorious.org/linted/linted/source/a1ab6d5024a4180cc9746e1a7807a6af16955255:src/linted-sandbox/sandbox.c . What’s hard is sandboxing the kernel doesn’t give you stuff like the GUI (X11 although Wayland improves on this) and PulseAudi like you mentioned. What I’m curious about is how did you handle read only recursive bind (or slave or other recursive) mounts? Also, see the bug at https://bugzilla.kernel.org/show_bug.cgi?id=24912 .
Just something that occurred to me later on.
> xdg-app-helper needs the CAP_SYSADMIN and CAP_MKNOD capabilities. It can either be installed with these file capabilities, or setuid root, in which case it will acquire the capabilities it needs and then go back to the real user id.
You know you don’t actually require this right? You can use CLONE_NEWUSER and lots of bind mounts and get sandboxing without elevating permissions in the first place. It’s also much more convenient for development.